home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 4033 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: zeus.clr.com!not-for-mail
  2. From: phil@zeus.clr.com (Phil Howard)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Microcom OH&BD problem circumvented
  5. Date: 5 Feb 1996 11:34:21 -0600
  6. Organization: fasttax.com
  7. Message-ID: <4f5f2t$4d0@zeus.clr.com>
  8. NNTP-Posting-Host: zeus.clr.com
  9.  
  10. Summary of problem:
  11.  
  12. Older and recent/current Microcom modems exhibit a symptom whereby they
  13. cease exchanging data at some point.  They remain connected and remain
  14. able to detect carrier loss or DTR loss, and therefore can be reset, even
  15. if the culprit modem is the remote one.  The problem occurs with Microcom
  16. modems on both ends or on just one.  An earlier experience when I used
  17. direct dialup and zmodem had a file download that always froze at exactly
  18. the same spot every time.  This problem is been seen in Microcom modems
  19. since some 14.4 rack mount ones and is in current rack mount and DeskPorte
  20. models.
  21.  
  22.  
  23. Circumvention:
  24.  
  25. Turn off compression.
  26.  
  27. If you are using PPP you probably have compression in your IP/PPP stack.
  28. For large file transfers, they are often already compressed anyway, such
  29. as .gif, .jpg, .zip, .gz, etc.  I see no noticeable loss in performance
  30. by having modem compression off.  I can now keep 24 hour connections.
  31.  
  32. You can turn off compression by adding "%C0" to your init string.  I do
  33. not know if the state is saved correctly since I never depend on anything
  34. to be saved as my init string for every dial attempt always reloads factory
  35. default settings and tweaks them from there, so I do "%C0" each time.
  36.  
  37.  
  38. Perhaps the compression logic is spinning in a CPU loop due to a bug in
  39. the code or in the data structures used to represent compression data
  40. state.  Perhaps the data is being altered due to something in compression
  41. and the checksum always fails and they perpetually retry (and it is very
  42. perpetual; I've seen the OH&BD stuck for over 12 hours before I pulled the
  43. plug).  I would have expected flow control to block data, but it does not
  44. do so, which tends to contradict some of this theory.
  45. -- 
  46. Phil Howard KA9WGN      +-------------------------------------------------+
  47. Unix/Internet/Sys Admin |    When freedom is outlawed....                 |
  48. CLR/Fast-Tax            |            ....only outlaws will be free!       |
  49. phil@clr.com            +-------------------------------------------------+
  50.